This section outlines at a high level the steps necessary to complete an information
organization project successfully. The first order of business will be
overcoming resistance to the idea that your company’s information really
does need to be organized.
So, how do you get others in
your company to accept the idea that they need to invest in an
information architecture, and more specifically, in a project that
leverages the information organization features in SharePoint 2010? This
is never easy because the objections of decision makers are entrenched
and familiar. Their objections usually center around
difficult-to-justify costs and other excuses that there just isn’t space
to list here.
Overcoming these objections is not easy, and it will take some real work on your part. To engage in an Information Organization Project
for SharePoint (IOPS), you’ll need to understand that you’re asking for
change in how information is developed, managed, and disseminated. Such
change is not a small thing. It is likely that there are many
information kingdoms in your organization, with people who already take
personal ownership of that information. That is not necessarily a bad
situation, but it is something that must be recognized and leveraged as
part of your IOPS effort.
There are
(essentially) six phases to an IOPS. The following sections outline each
phase and provide you with tools for achieving your goal of
establishing a successful IOPS.
Note:
MORE INFO
There are other paths that can be followed to help you with your
SharePoint 2010 implementation. For example, BearingPoint has released
its methodology on how to organize information, which is an open source
standard for information management. You can learn more about this at http://mike2.openmethodology.org/. Moreover, the AIIM (Association for Information and Image Management, http://www.aiim.org)
group has published several certifications that relate to SharePoint
2010 implementations. These are the Enterprise Content Management
Specialist and Information Organization Specialist credentials. At the
time of this writing, AIIM is introducing a SharePoint Specialist
certification that bridges the gap between the SharePoint technology and
their expertise in how to manage information. The phases presented in
the following sections represent a suggested path on how to achieve a
strong organization of information in SharePoint 2010. But this is only a
suggested path. You might find that using the MIKE 2.0, AIIM, or
another methodology will work better for your organization.
The information
organization project introduced in the following sections is divided
into six basic phases, as explained previously. The early phases are the
most important, and each subsequent phase builds on the previous one.
Moreover, the quality of success at each phase will directly impact the
quality of success in the following phases.
1. Phase 0: Information Organization Assessment
In the first phase of the
project, you’ll want to gather information about its scope, including
who the main stakeholders will be. You will also want to inform yourself
about the environment in which you’re working. Don’t be fooled into
thinking that you can bypass this stage because you are working on your
own environment. Completing an information organization assessment
questionnaire will enable you to collect what you need to know at the
start of the project, to keep everyone involved informed of the
project’s progress, and to set proper expectations on how the IOPS will
flow.
The questionnaire should cover the following topics.
Definition of the documents that are in scope versus those that are out of scope
Definition of the systems that are in scope versus those that are out of scope
Definition of the processes and policies that are in scope versus those that are out of scope
Statement of the technical environment that currently exists and what changes must be made to support the IOPS effort
Definition of the problem that has given rise to the need for this project
Definition of the desired outcome, which should be stated in measurable terms
Discussion of the interview data that supports the project’s effort
Statement of the project’s sponsor, project manager, and champion
Outline of the communication plan for the project
Outline of the project plan
As you can see in Figure 1,
there is more to this phase than mere documentation of the problem,
solution, and current environment. You also should document explicit
business needs (not requirements), and you should conduct a cost of
doing business analysis (CODB). Writing out the business needs is really
how you’ll define the findability problem in business terms. The
persona interviews (explained later in this section) illustrate those
needs in an easy-to-understand way, and the CODB quantifies the severity
of the problem in opportunity costs.
In this first phase, you also
need to conduct a CODB analysis. This is different from a return on
investment (ROI) analysis. In nearly all companies, the value of their information
doesn’t appear on the balance sheet, so it’s nearly impossible to
calculate a hard return on investment against the cost of an IOPS.
However, you can more easily calculate savings based on increased
efficiencies as a result of an IOPS. Those calculations need to be
completed in Phase 0.
Do not overlook the
persona interviews, because they form the basis of a CODB. Having a
business analyst document current processes and the cost of those
processes provides the foundation against which the savings calculation
can be made. Persona interviews are conducted with real people whose
stories and daily lives in the workplace are folded into a composite
person with a fictitious name. When you have developed that persona,
this fictitious person is used as an example of how the IOPS will
improve that employee’s life. It’s usually best if three to five
personas are developed, because different employee types will be
affected in different ways.
You’ll also need to do a
findability study before you can create the statement of work (SOW).
You’ll need to gather both anecdotal and measured responses concerning
how well employees are able to find the information
they need and how easy that transaction is. Don’t worry about measuring
putability in this phase, since a poor findability solution will point
out deficits in your putability processes.
When all of these
activities are combined, you’ll be able to describe the problem in real
terms, quantify the opportunity costs in real dollars, express how the
IOPS will improve efficiencies, and illustrate how the day-to-day work
lives of employees will improve. All of this is included in a statement
of work and is usually connected to a request for additional funding to
complete the next four phases. At the end of Phase 0, you have outlined
the costs, the staff, and the cycles necessary to complete the IOPS.
2. Phase 1: Business Requirements Development
In this phase, you’ll
focus on the development of the business requirements based on
stake-holder interviews, the problem definitions from Phase 0, and a
grassroots survey. You’ll want to document the requirements and then
hold a series of requirements workshops to check the requirements and
ensure that everyone agrees on the definition of the problem as well as
what is required in the solution.
This phase, illustrated in Figure 2,
is an important step that involves much writing and consensus building,
but it will not complete the groundwork for your IOPS. However,
developing the business requirements in this phase is a necessary step
to prepare for Phase 2, which involves turning these business
requirements into technical requirements.
It could be argued that the
business requirement effort should be moved back to Phase 0, and in some
environments this will be the right way to conduct the IOPS. Placing
the effort to develop business requirements in Phase 1, after the project
has been approved and funded (which occurs after Phase 0), usually
makes more sense, however, because of the cost and time consumption
required to develop requirements. You would move the requirements
development to Phase 0 if you were working with a customer who didn’t
need or want a cost justification for an IOPS, because they have already
decided to get their information organized, and cost is a secondary
consideration.
3. Phase 2: Technical Requirements and Project Charter
In this phase, shown in Figure 3,
you will focus on taking the business requirements and turning them
into technical requirements. These technical requirements will connect
your specific business requirements with the feature set available in
SharePoint 2010. The technical requirements will also outline the
current state of your organization’s hardware and software and then
describe any changes necessary to deploy SharePoint 2010 for your information
organization project. Also as part of this phase, you’ll need to
document your current governance plan for SharePoint 2010 and then
outline any modifications required as part of the SharePoint 2010
implementation.
The combination of the outputs from the first three phases will form the content and rationale for the project
charter, which everyone involved should agree to before the project
moves forward. Assume at this point that you have funding for the IOPS
and the authority for those leading the project to make decisions,
approve expenditures, and implement policy changes.
4. Phase 3: Audit and Analysis
Taking the output from Phase 2,
you now need to inventory the documents and records that are in scope
for the project and determine their security assignments. This should be
an exhaustive inventory and will require third-party tools that can
enumerate both the complete list of documents and well as their security
descriptors.
This part of an IOPS
can be rather difficult, because in the course of conducting the
inventory, you want to discover old, outdated, or irrelevant data that
can be discarded. You’re working with a multitude of content owners to
help them decide which documents they need to keep and which ones need
to go. You’re also uncovering security problems with documents and
finding security processes and policies that will need to be updated to
ensure the same problems don’t occur again.
As part of Phase 3, you’ll
need to ensure that you have good communication with your users, because
they will be guiding your decisions about which artifacts to keep and
which to discard. It is not uncommon to encounter resistance at this
phase from users who will claim that they don’t have time to help with
this decision-making process. At the beginning of the project, this
resistance should be anticipated and addressed. Some ideas for managing
this resistance include gaining authority to discard files that are more
than a specified number of months or years old or to move documents
that have not been included in the inventory into an unsupported file
server that will be excluded from the project. Figure 4 illustrates the activities for this phase.
5. Phase 4: Development of Putability and Findability
In Phase 4, you
develop the operational taxonomies, user interfaces, tagging policies,
and educational materials that users will utilize in their ongoing
management of information. This is a busy phase and involves high
involvement for your end users. This highly visible phase must go well
to ensure that your project is successful.
In Phase 4, you will conduct nearly all of the
tasks described in that section—the development of the business
taxonomy can be conducted in parallel with Phases 0 through 3 in this
larger methodology, but the rest of those activities will occur in the
current phase. Refer to the detail provided in the previous discussion. Figure 5 illustrates the development of putability and findability in your information
organization project. When you have planned the information
architecture that will provide the structure for your project, it’s time
to move on to Phase 5, in which you will address the governance and
maintenance of your information organization systems.
6. Phase 5: Governance and Maintenance
Phase 5 is an ongoing stage that supports and maintains not only the SharePoint 2010 implementation,
but also the ongoing organization of information within the SharePoint
implementation. Information will change over time, so your company may
need to adjust the rules that guide how the information is organized and
tagged. By regularly reviewing how information is managed, tagged,
input, and found, you will help ensure that your efforts to organize
information in SharePoint 2010 have not gone to waste.
Also, as your company
matures in the area of managing information effectively, the governance
rules that guide end users and the enforcement of those rules also will
necessarily change. Ensure that you have a process for this change in
place, and that there are identified personnel who are capable and
authorized to make changes to the governance rules. Also make sure that
these people can communicate those changes to your entire organization
clearly and effectively.
Figure 6 illustrates this last phase, which is never really complete. By their
nature, maintenance, review, assessment, and training are ongoing tasks
that must continue indefinitely. As your organization changes and grows,
you will need to make sure your information architecture can adapt. And
as new employees join your company, you also need to be sure that they
are trained properly in using the system you have in place. Orientation
materials for new employees should cover your information architecture
structure, its policies and procedures, and the rules of enforcement so
that your organization doesn’t experience incremental loss of use in information organization because of employees who don’t understand how the system works.
